https://192.168.3.102/owncloud/ Generated on 2014-12-10 11:10:53 +0100

In the majority of today’s web applications, clients are required to submit forms which can perform sensitive operations.

An example of such a form being used would be when an administrator wishes to create a new user for the application.

In the simplest version of the form, the administrator would fill-in:

• Name
• Password
• Role (level of access)

Continuing with this example, Cross Site Request Forgery (CSRF) would occur when the administrator is tricked into clicking on a link, which if logged into the application, would automatically submit the form without any further interaction.

Cyber-criminals will look for sites where sensitive functions are performed in this manner and then craft malicious requests that will be used against clients via a social engineering attack.

There are 3 things that are required for a CSRF attack to occur:

1. The form must perform some sort of sensitive action.
2. The victim (the administrator the example above) must have an active session.
3. Most importantly, all parameter values must be known or guessable.

Arachni discovered that all parameters within the form were known or predictable and therefore the form could be vulnerable to CSRF.

Manual verification may be required to check whether the submission will then perform a sensitive action, such as reset a password, modify user profiles, post content on a forum, etc.

If a server has been previously compromised, there is a high probability that the cyber-criminal has installed a backdoor so that they can easily return to the server if required. One method of achieving this is to place a web backdoor or web shell within the web root of the web server. This will then enable the cyber-criminal to access the server through a HTTP/S session.

Although extremely bad practice, it is possible that the web backdoor or web shell has been placed there by an administrator so they can perform administrative activities remotely.

During the initial recon stages of an attack, cyber-criminals will attempt to locate these web backdoors or shells by requesting the names of the most common and well known ones.

By analysing the response, they are able to determine if a web backdoor or web shell exists. These web backdoors or web shells can then provide an easy path for further compromise of the server.

By utilising the same methods as the cyber-criminals, Arachni was able to discover a possible web backdoor or web shell.

A common practice when administering web applications is to create a copy/backup of a particular directory prior to making any modification. Another common practice is to add an extension or change the name of the original directory to signify that it is a backup (examples include .bak, .orig, .backup, etc.).

During the initial recon stages of an attack, cyber-criminals will attempt to locate backup directories by adding common extensions onto directories already discovered on the webserver. By analysing the response headers from the server they are able to determine if a backup directory exists. These backup directories can then assist in the compromise of the web application.

By utilising the same method, Arachni was able to discover a possible backup directory.

A common practice when administering web applications is to create a copy/backup of a particular file or directory prior to making any modification to the file. Another common practice is to add an extension or change the name of the original file to signify that it is a backup (examples include .bak, .orig, .backup, etc.).

During the initial recon stages of an attack, cyber-criminals will attempt to locate backup files by adding common extensions onto files already discovered on the webserver. By analysing the response headers from the server they are able to determine if the backup file exists. These backup files can then assist in the compromise of the web application.

By utilising the same method, Arachni was able to discover a possible backup file.

The HTTP protocol by itself is clear text, meaning that any data that is transmitted via HTTP can be captured and the contents viewed. To keep data private and prevent it from being intercepted, HTTP is often tunnelled through either Secure Sockets Layer (SSL) or Transport Layer Security (TLS). When either of these encryption standards are used, it is referred to as HTTPS.

HTTP Strict Transport Security (HSTS) is an optional response header that can be configured on the server to instruct the browser to only communicate via HTTPS. This will be enforced by the browser even if the user requests a HTTP resource on the same server.

Cyber-criminals will often attempt to compromise sensitive information passed from the client to the server using HTTP. This can be conducted via various Man-in-The-Middle (MiTM) attacks or through network packet captures.

Arachni discovered that the affected application is using HTTPS however does not use the HSTS header.

Web applications are often made up of multiple files and directories.

It is possible that over time some directories may become unreferenced (unused) by the web application and forgotten about by the administrator/developer. Because web applications are built using common frameworks, they contain common directories that can be discovered (independent of server).

During the initial recon stages of an attack, cyber-criminals will attempt to locate unreferenced directories in the hope that the directory will assist in further compromise of the web application. To achieve this they will make thousands of requests using word lists containing common names. The response headers from the server will then indicate if the directory exists.

Arachni also contains a list of common directory names which it will attempt to access.

In typical form-based web applications, it is common practice for developers to allow autocomplete within the HTML form to improve the usability of the page. With autocomplete enabled (default), the browser is allowed to cache previously entered form values.

For legitimate purposes, this allows the user to quickly re-enter the same data when completing the form multiple times.

When autocomplete is enabled on either/both the username and password fields, this could allow a cyber-criminal with access to the victim’s computer the ability to have the victim’s credentials automatically entered as the cyber-criminal visits the affected page.

Arachni has discovered that the affected page contains a form containing a password field that has not disabled autocomplete.

Web applications are often made up of multiple files and directories.

It is possible that over time some files may become unreferenced (unused) by the web application and forgotten about by the administrator/developer. Because web applications are built using common frameworks, they contain common files that can be discovered (independent of server).

During the initial recon stages of an attack, cyber-criminals will attempt to locate unreferenced files in the hope that the file will assist in further compromise of the web application. To achieve this they will make thousands of requests using word lists containing common filenames. The response headers from the server will then indicate if the file exists.

Arachni also contains a list of common file names which it will attempt to access.

Private, or non-routable, IP addresses are generally used within a home or company network and are typically unknown to anyone outside of that network.

Cyber-criminals will attempt to identify the private IP address range being used by their victim, to aid in collecting further information that could then lead to a possible compromise.

Arachni discovered that the affected page returned a RFC 1918 compliant private IP address and therefore could be revealing sensitive information.

_This finding typically requires manual verification to ensure the context is correct, as any private IP address within the HTML body will trigger it.

Email addresses are typically found on “Contact us” pages, however, they can also be found within scripts or code comments of the application. They are used to provide a legitimate means of contacting an organisation.

As one of the initial steps in information gathering, cyber-criminals will spider a website and using automated methods collect as many email addresses as possible, that they may then use in a social engineering attack.

Using the same automated methods, Arachni was able to detect one or more email addresses that were stored within the affected page.

Logs the existence of HTML object tags. Since Arachni can’t execute things like Java Applets and Flash this serves as a heads-up to the penetration tester to review the objects in question using a different method.

The server responded with a non 200 (OK) nor 404 (Not Found) status code. This is a non-issue, however exotic HTTP response status codes can provide useful insights into the behavior of the web application and assist with the penetration test.

The design of many web applications require that users be able to upload files that will either be stored or processed by the receiving web server.

Arachni has flagged this not as a vulnerability, but as a prompt for the penetration tester to conduct further manual testing on the file upload function.

An insecure form-based file upload could allow a cyber-criminal a means to abuse and successfully exploit the server directly, and/or any third party that may later access the file. This can occur through uploading a file containing server side-code (such as PHP) that is then executed when requested by the client.

HTTP by itself is a stateless protocol. Therefore the server is unable to determine which requests are performed by which client, and which clients are authenticated or unauthenticated.

The use of HTTP cookies within the headers, allows a web server to identify each individual client and can therefore determine which clients hold valid authentication, from those that do not. These are known as session cookies.

When a cookie is set by the server (sent the header of an HTTP response) there are several flags that can be set to configure the properties of the cookie and how it is to be handled by the browser.

The HttpOnly flag assists in the prevention of client side-scripts (such as JavaScript) accessing and using the cookie.

This can help prevent XSS attacks targeting the cookies holding the client’s session token (setting the HttpOnly flag does not prevent, nor safeguard against XSS vulnerabilities themselves).

HTTP by itself is a stateless protocol. Therefore the server is unable to determine which requests are performed by which client, and which clients are authenticated or unauthenticated.

The use of HTTP cookies within the headers, allows a web server to identify each individual client and can therefore determine which clients hold valid authentication, from those that do not. These are known as session cookies.

When a cookie is set by the server (sent the header of an HTTP response) there are several flags that can be set to configure the properties of the cookie and how it is to be handled by the browser.

One of these flags is known as the secure flag. When the secure flag is set, the browser will prevent it from being sent over a clear text channel (HTTP) and only allow it to be sent when an encrypted channel is used (HTTPS).

Arachni discovered that a cookie was set by the server without the secure flag being set. Although the initial setting of this cookie was via an HTTPS connection, any HTTP link to the same server will result in the cookie being send in clear text.

A common practice when administering web applications is to create a copy/backup of a particular directory prior to making any modification. Another common practice is to add an extension or change the name of the original directory to signify that it is a backup (examples include .bak, .orig, .backup, etc.).

During the initial recon stages of an attack, cyber-criminals will attempt to locate backup directories by adding common extensions onto directories already discovered on the webserver. By analysing the response headers from the server they are able to determine if a backup directory exists. These backup directories can then assist in the compromise of the web application.

By utilising the same method, Arachni was able to discover a possible backup directory.

A common practice when administering web applications is to create a copy/backup of a particular file or directory prior to making any modification to the file. Another common practice is to add an extension or change the name of the original file to signify that it is a backup (examples include .bak, .orig, .backup, etc.).

During the initial recon stages of an attack, cyber-criminals will attempt to locate backup files by adding common extensions onto files already discovered on the webserver. By analysing the response headers from the server they are able to determine if the backup file exists. These backup files can then assist in the compromise of the web application.

By utilising the same method, Arachni was able to discover a possible backup file.

Web applications are often made up of multiple files and directories.

It is possible that over time some directories may become unreferenced (unused) by the web application and forgotten about by the administrator/developer. Because web applications are built using common frameworks, they contain common directories that can be discovered (independent of server).

During the initial recon stages of an attack, cyber-criminals will attempt to locate unreferenced directories in the hope that the directory will assist in further compromise of the web application. To achieve this they will make thousands of requests using word lists containing common names. The response headers from the server will then indicate if the directory exists.

Arachni also contains a list of common directory names which it will attempt to access.

Web applications are often made up of multiple files and directories.

It is possible that over time some files may become unreferenced (unused) by the web application and forgotten about by the administrator/developer. Because web applications are built using common frameworks, they contain common files that can be discovered (independent of server).

During the initial recon stages of an attack, cyber-criminals will attempt to locate unreferenced files in the hope that the file will assist in further compromise of the web application. To achieve this they will make thousands of requests using word lists containing common filenames. The response headers from the server will then indicate if the file exists.

Arachni also contains a list of common file names which it will attempt to access.